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Columbus  Laboratories 
505  King  Avenue 
Columbus,  Ohio  43201 
Telephone  (61 4)  424-6424 
Telex  24-5454 


Tuly  12,  1980 


Mr.  Coye  Bridges 
DCS/Plans  and  Programs 
Air  Force  Logistics  Command 
Wright-Pat terson  AFB,  Ohio  45433 

Dear  Coye: 


Reference  Contract  No.  F33600-80-C-0414 


Enclosed  is  the  deliverable  for  Task  3(a)R,  Requirements  Planning  Session  Outline 
due  11  weeks  after  contract  award. 

In  developing  this  outline,  Battelle  has  formed  the  or'.nion  that  the  requirements 
sessions  should  be  heavily  workshop  oriented  to  take  full  advantage  of  the  opera¬ 
tional  logistics  experience  of  the  participants.  Battelle  recommends  that  the 
process  of  informing  the  participants  on  the  background  of  the  LMS  project  be 
distributed  over  the  entire  session  and  that  the  participants  be  given  productive 
work  on  the  first  day  of  the  session  following  a  brief  overview  of  the  program. 

In  this  way  we  expect  to  involve  the  participants  early  and  create  a  strong  posi¬ 
tive  approach  for  the  remainder  of  the  session. 

In  addition  to  the  required  deliverable,  I  have  enclosed  a  paper  that  describes 
the  process  of  moving  from  an  LMS  need  to  an  LMS  requirement.  This  paper  is 
presented  for  your  critique.  We  found  it  useful  in  defining  the  output  of  the 
requirements  session  and  in  turn  organizing  the  sessions. 

Please  let  me  know  if  we  need  to  get  together  to  discuss  this  deliverable. 

Sincerely, 


J.  Douglas  Hill 
Research  Leader 

Defense  Systems  &  Technology  Section 

JDH:alm 

Enc. 
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TASK  3(a).:  REQUIREMENTS  SESSION  OUTLINE 
& 

* 

The  following  outlines  activities  planned  for  the  LMS  Require¬ 
ments  Planning  Session  scheduled  for  September  15.  The  outline  is 
presented  in  a  manner  that  can  be  readily  applied  to  any  topic  area; 
however,  it  is  assumed  that  the  topic  area  will  be  Maintenance  Production 
Management  which  will  build  on  the  results  of  one  of  the  two  topic  areas 
from  the  Needs  Planning  Session  in  July.  It  is  expected  that  this  outline 
may  be  revised  substantially  based  on  future  work  and  the  results  of  the 
July  sessions . 

OUTLINE  OF  LOGISTICS  MANAGEMENT 
SYSTEM  REQUIREMENTS  PLANNING  SESSION 

Requirements  Session  Objectives 


To  Be  Achieved  Through  Presentation 

#  To  understand  and  support  the  recommended  planning 
approach 

e  To  understand  and  support  the  concept  of  incremental 
renewal  of  LMS 

#  To  understand  the  LAG  concept  and  to  accept  it  as 
the  basis  for  LMS  planning 

e  To  understand  the  roles  of  Battelle  and  AFLC  in 
IMS  planning 

e  To  understand  the  purpose,  relevance,  and  results  of 
the  IMS  Policy  Planning  and  LMS  Needs  Planning  Sessions 

e  To  understand  the  LAG  representation  of  the  operation 
of  the  topic  area 

a  To  understand  the  meaning,  purpose,  format,  and 
attributes  of  LMS  requirements 

e  To  understand  the  importance  of  relating  the  LM  and  LMS 
concepts,  the  LMS  principles,  and  the  LMS  needs  to  the 
determination  of  the  LMS  requirements 

a  To  understand  the  importance  of  relating  the  IMS 

requirements  to  the  determination  of  the  LMS  design,  the 
data  aystem  requirements  planning,  and  the  data  system 


•  To  understand  the  LMS  needs  identified  for  the  topic 

area  in  the  LMS  Needs  Planning  Session  and  their  relation 
to  the  current  and  future  requirements  for  management 
information  and  functions. 


To  Be  Achieved  Through  Group  Participation 


To  validate  or  enhance  the  LAG  representation  of  the  operation 
of  the  topic  area 

To  identify  the  IMS  requirements  necessary  to  fulfill  the 
current  and  future  requirements  of  the  topic  area  for  ~  ■' , 

management  information  and  functions  An  terms  of  the  IMS') 
needs  identified  in  IMS  Needs  Plaining  Session^ 

To  document  the  IMS  requirements  at  a  level  of  detail  and  '  ~~ 

in  a  format  suitable  for  input  to  the  IMS  design  for  the 
topic  area 

To  critique  the  group  planning  session  in  terms  of  methods, 
materials,  and  results. 


IMS  Requirements  Session  Agenda 


ggy.JL 

0830- 

0900 


0900- 

0930 


0930- 

1030 


1030- 

1200 


1)  Opening  remarks 

1.1  Brief  keynote — AILC  Vice  Commander 

1.2  Administrative  comments 

2)  Overview  of  3  1/2  day  meeting 

2.1  Objective 

2 . 2  Scope 

2.3  Schedule 

2.4  Expected  results 

3)  Summary  of  background 

3.1  Past  planning 

3.2  Interim  (current)  planning  study 

3.3  Future  directions  and  activities 

4)  Introduction  to  topic  area  and  associated  LAG 

4.1  Rationale  for  LAG's 

4.2  LAG  framework 

4.3  Presentation  and  discussion  of  topic  area 
and  associated  initial  LAG  representation 


5)  Validation  and/or  enhancement  of  LAG 

representation  of  topic  area 

5.1  .  Explanation  of  objective 

5.2  Presentation  of  group  methodology  to  be  used 

5.3  Instructions  for  validation/enhancement  of  LAG 

5.4  Interactive  group  idea  generation 

5.4.1  Divide  participants  into  groups  of  5-6 
participants 

5.4.2  Each  group  selects  a  session  recorder 

5.4.3  Assign  logic  clusters  of  LAG  for  topic 
area  to  groups 

5.4.4  Each  group  validates /enhances  logic 
clusters  assigned  to  it 

5.4.5  Reconvene  and  consolidate  results — 
no  discussion  or  critique 


5.5  Discussion,  cross feed,  and  critique  of  group's 
findings 

5.5.1  Each  session  recorder  presents  and 
discusses  informally  the  results  of 
group' 8  work 

5.5.2  Each  group  responds  to  questions  and/or 
criticisms  of  its  work 

5.5.3  Validated/enhanced  logic  clusters  are 
annotated  or  supplemented  as  necessary 
to  document  questions  or  criticisms 

6)  Introduction  to  LMS  requirements'  development 

6.1  Presentation  and  discussion  of  LMS  background 
concepts 

6.1.1  LM  and  LMS  concepts 

6.1.2  LMS  development  methodology 

6.1.3  LMS  principles 

6.1.4  IMS  Policy  Planning  Session 

6.1.5  LMS  Needs  Planning  Session 

6.2  Presentation  of  LMS  hypothetical  requirements 
development  example  showing  the  development 
of  an  LMS  requirement  from  an  LMS  need 

6.3  Presentation  and  discussion  of  LMS  needs  as 
they  relate  to  topic  area 
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7)  Development  of  LMS  requirements  for  LMS  needs 

7.1  Explanation  of  objective 

7.2  Presentation  of  proup  methodology  to  be  used 

7.3  Instructions  for  defining  LMS  requirements 

7.4  Interactive  group  idea  generation 

7.4.1  Use  same  group  logic  cluster  align¬ 
ment  as  in  session  5.4 

7.4.2  Each  group  selects  a  session  recorder 

7.4.3  Each  group  defines  the  LMS  require¬ 
ments  resulting  from  the  impact  of  the 
LMS  needs  on  its  logic  clusters 

7.5  Reconvene  for  crossfeed 

7.5.1  Each  session  recorder  reports  progress 

7.5.2  Open  discussion  and  cross feed 


7.6  Interactive  group  idea  generation — 

7.6.1  Work  of  7.4.3  is  continued 

8)  Presentation  of  LMS  requirements 

8.1  Reconvene  and  session  recorder  presents  and 
discusses  the  LMS  requirements  for  each  group 

8.2  Each  group  responds  to  questions  and/or 
criticism  of  its  LMS  requirements 

9)  Integration  of  LMS  requirements 

9.1  LMS  requirements  are  aggregated 

9.2  Duplications  of  LMS  requirements  are  deleted 

9.3  New  requirements  are  added  if  needed 

9.4  Questionable  requirements  are  so  noted 

9.5  Assess  criticality  of  requirements 


10)  Documentation  of  LMS  requirements 

10.1  Each  group  documents  in  the  prescribed 
format  the  LMS  requirements  for  its  logic 
cluster (8) 

10.2  Relationship  of  requirement  to  LMS  needs 
is  shown 


10.3  Relationship  of  requirement  to  LAG/logic 
cluster  is  shown 

10.4,  External  interfaces  identified 
11)  Critique  of  session — feedback  from  participants 

11.1  How  do  actual  results  compare  with 
expected  results? 

11.2  Hill  results  be  useful  for  data  systems 

t)~;  requirement  planning  and  data  system  design? 

11.3  Are  planning  methods  suitable  for  developing 
pollcy/needs-driven  requirements? 

11.4  Is  the  LAG  representation  a  suitable  tool  for 
understanding  the  topic  area  and  defining  its 
LMS  requirements? 

11.5  Are  the  materials  suitable  for  the  purposes  of 
the  session  and  do  they  contribute  to  its  value? 


11.6  Do  the  methods  used  ensure  user  primacy? 
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LMS  HYPOTHETICAL  REQUIREMENTS  DEVELOPMENT 


PURPOSE 


This  paper  is  intended  to  walk  through  the  process  of  LMS  requirements 
development  as  a  means  of  clarifying  the  process.  It  is  expected  that  an  example 
which  moves  from  a  long-range  logistics  need  to  a  specific  LMS  requirement  will 
define  the  differences  between  needs,  requirements,  and  specifications  in  a  way 
that  will  be  beneficial  to  participants  in  the  requirements  sessions. 

APPROACH 

In  this  paper  a  plausible  but  hypothetical  need  will  be  generated  as 

if  it  had  originated  in  the  planning  sessions.  That  need  will  be  transformed 

into  an  LMS  need  in  the  topical  area  of  Maintenance  Production  Management  as 
it  might  be  expected  to  be  transformed  in  the  needs  sessions.  It  will  then  be 

operated  on  as  we  would  expect  in  the  requirements  sessions  and  output  as  an 

LMS  requirement.  Tiis  example  will  serve  as  a  test  of  the  form  of  the  products 
to  be  generated  by  .'.he  requirements  sessions. 

The  Logistics  Need 


Consider  the  hypothetical  situation  where  the  logistics  policy  session 
determines  that  in  the  future  AFLC  will  be  expected  to  support  multiple  contin¬ 
gencies  of  relatively  small  size  and  short  duration  with  critical  political 
consequences.  The  policymakers  determine  that  it  will  be  necessary  for  AFLC  to 
adjust  outputs  on  short  notice  to  support  these  contingencies.  Due  to  limita¬ 
tions  on  resources,  AFLC  will  be  expected  to  adjust  outputs  for  selected  systems 
or  segments  of  systems  in  order  to  apply  the  required  effort  to  critical  areas. 

When  considering  this  logistics  need  in  the  needs  session  devoted  to 
Maintenance  Production  Management,  the  session  reviewed  the  potential  contin¬ 
gency  requirements  and  developed  a  set  of  needs  based  on  these  contingencies. 

One  of  the  contingencies  considered  representative  was  the  rapid  deployment  of 


two  wings  of  F-4's  to  a  country  such  as  Pakistan  for  a  period  of  90  days.  While 
deployed  the  F-4  will  operate  at  a  maximum  sortie  rate  in  a  close-air  support 
role  in  a  dense  threat  environment.  The  needs  session  translates  this  into  a 
depot  workload  need  which  states, 

"AFLC  must  have  the  ability  to  adjust  depot  workloads  to  meet 
the  specialized  support  requirements  of  small  groups  of  air¬ 
craft  deployed  for  that  period  (90  days)  in  intensive  opera¬ 
tion.  AFLC  must  be  able  to  adjust  depot  output  of  specialized 
assets  to  meet  such  contingencies  with  minimum  degradation  of 
support  to  other  units.  AFLC  must  be  capable  of  deploying 
specialized  support  teams  within  five  days  to  support  contin¬ 
gency  operations." 

In  developing  this  specific  need  the  needs  session  developed  several 
other  needs  that  when  taken  together  will  meet  the  policy  objectives  in  the 
area  of  Maintenance  Production  Management.  Only  the  specific  need  stated  will 
be  followed  in  this  example. 


The  Requirement 


The  requirements  session  dedicated  to  Maintenance  Production  Management 
examined  the  LAG  or  LAGs  associated  with  meeting  the  set  of  needs  defined  by  the 
needs  session.  They  applied  their  combined  knowledge  of  Maintenance  Production 
Management  to  defining  what  would  be  involved  in  satisfying  the  stated  need. 

They  observed  that  if  the  ability  to  control  or  adjust  depot  output  to  the  level 
Indicated  by  the  need  were  to  exist,  several  subcrdinate  capabilities  would  be 
required.  For  example,  they  would  need: 

•  Visibility  on  current  asset  position  and  a  valid  projection 
of  asset  position  over  the  period  of  the  contingency 

•  A  means  of  assessing  the  demand  rate  for  the  deployed  units 
for  each  asset.  This  capability  must  include  a  means  of 
projecting  demand  rates  for  seldom-used  assets  such  as  ECM 
equipment. 

•  A  means  of  predicting  specialized  support  team  requirements 
for  logistics  support,  battle  damage  repair  and  so  forth 

•  An  effective  means  for  assessing  the  impact  on  other  units 
if  priority  is  shifted  to  the  deployed  units.  This  capa¬ 
bility  must  include  the  ability  to  adjust  priority  by 
commodity  to  pace  the  effort  on  limiting  factors. 

•  A  means  of  selectively  expediting  critical  assets  with 
minimum  overall  impact 


•  A  means  of  redirecting  assets  from  the  worldwide  asset 
pool  to  meet  short-term  requirements. 

The  requirements  session  then  reviewed  the  existing  LKS  to  determine 
the  extent  to  which  they  would  meet  the  requirement.  Where  shortfalls  were 
identified  the  session  participants  defined  required  changes.  For  example, 
a  requirement  was  defined  to  modify  DO-41  to  allow  a  weekly  recomputation  based 
on  the  short-term  requirements  of  the  deployed  units.  This  computation  is  then 
used  to  adjust  the  M1STR  drive  for  items  projected  to  be  critical  and  to 
redirect  assets  previously  shipped  to  lower  priority  units.  A  system  to  assess 
the  short-term  impact  of  these  adjustments  on  non-deployed  units  was  laid  out 
as  a  requirement.  In  the  process  of  defining  this  requirement  the  session 
participants  preserved  the  requirements  to  meet  existing  logistics  operations 
and  to  the  best  of  their  ability  listed  the  existing  requirements  in  addition 
to  the  new  requirement.  The  session  defined  the  performance  required  of  these 
system  changes  but  did  not  define  how  the  requirements  would  be  met.  This  was 
left  to  the  LMS  design  group. 

For  each  requirement  the  session  members  called  out  the  performance 
requirement  in  terms  of  what  must  be  done.  For  example,  in  the  area  of  con¬ 
trolling  workload  in  progress  they  defined  the  following  requirement: 

Objective:  To  provide  a  means  of  controlling  workload  in  progress 
with  weekly  adjustments  to  meet  contingency  needs.  (Note:  Weekly 
update  was  selected  based  on  the  response  time  of  the  maintenance 
system  and  the  desire  to  avoid  disruptive  adjustments  to  the 
production  function.) 

Requirement :  AFLC  requires  a  system  to  adjust  and  control  depot 
workload  (organic  and  contract)  on  a  weekly  basis.  The  system 
must  be  capable  of  responding  to  a  specific  asset,  a  subsystem, 
a  segment  of  a  weapon  system,  a  weapon  system  or  multiple-weapon 
systems.  It  must  be  capable  of  assessing  the  need  for  adjustment 
and  the  Impact  of  these  adjustments  on  other  assets  in  the  same 
production  function. 


